The deletable scope only considered polymorphic related_object
references, which missed attachments linked from /attachment/:id/download
URLs written into ingredient values by the file tab of the link dialog.
On sites where attachments are linked from Richtext, Link, or Html
ingredients, every attachment was reported as deletable, risking
accidental data loss.

The scope now adds a correlated NOT EXISTS against ingredient value
columns. The per-row LIKE pattern is built with Arel::Nodes::Concat so
it compiles to || on SQLite and PostgreSQL and to CONCAT() on MySQL
without adapter-specific SQL. The /download suffix in the pattern
delimits the id, so matching attachment 1 does not incorrectly pull in
URLs pointing at attachment 10.

(cherry picked from commit 3ed90b4)

Rendering the attachment index used to call Attachment#deletable? per
row to decide which delete buttons to enable. Each call issued up to
two queries (the polymorphic related_ingredients check and the LIKE
scan for ingredient-value references), so a page of N attachments cost
up to 2N extra queries in addition to the main fetch.

The controller now runs the deletable scope once for the ids on the
current page and stores the result in a Set. Because the scope relation
is chained as the subquery source of an IN clause, Rails applies the
same Ransack filter, sort, and pagination on the database side without
materializing the ids Ruby-side, keeping the check tight to the rows
the view actually renders.

(cherry picked from commit f425112)

Rendering the picture archive used to call Picture#deletable? per row
to decide which delete buttons to show. Each call issued up to two
queries (the polymorphic related_ingredients check and the LIKE scan
for ingredient-value references), so a page of N pictures cost up to
2N extra queries in addition to the main fetch.

The controller now runs the deletable scope once for the ids on the
current page and stores the result in a Set. Because the scope relation
is chained as the subquery source of an IN clause, Rails applies the
same Ransack filter, sort, and pagination on the database side without
materializing the ids Ruby-side, keeping the check tight to the rows
the view actually renders. The same preload is wired to the update
action since it re-renders the picture partial via turbo stream.

(cherry picked from commit f32d773)